OpenEdge Deployment:<br />Managing 4GL Applications Standard r-code execution environment

Standard r-code execution environment

At run time, OpenEdge manages the execution of a standard r-code procedure from either an operating system file or a standard procedure library using the following components:

Execution buffer — The portion of local memory that OpenEdge allocates and uses to store the chain of loaded r-code segments for all procedures executing in local memory.

Session sort file (.srt) — A file that OpenEdge uses to dynamically swap r-code segments in and out of the execution buffer.

Segment descriptor table — An in-memory table that references the r-code segments required by all executing procedures, including the location of each r-code segment in the execution buffer and usage count information.

R-code directory — An in-memory table that contains information about each executing r-code procedure, including r-code size, usage count, segment descriptions, and a reference to the segment descriptor table for each segment.

OpenEdge uses the segment descriptor table and the r-code directory to manage r-code procedures from operating system files, standard libraries, and memory-mapped libraries.

Figure B–2 shows the layout for the standard r-code execution environment.

Figure B–2: Standard r-code execution environment

In Figure B–2, OpenEdge located and loaded the cust.r and orders.r files into local memory from either operating system files or standard libraries. The execution buffer is shown with three cust.r segments and two orders.r segments. Note that one orders.r segment is located in the execution buffer, while the other segment is swapped to the session sort file. When space in the execution buffer is needed for new r-code segments, OpenEdge uses the session sort file to swap out the least-recently used segments. When OpenEdge needs a segment that has been swapped to the session sort file, it reloads the segment from the session sort file into the execution buffer.

Standard execution sequence

When you run a standard r-code procedure for the first time, from either an operating system file or a standard library, OpenEdge loads and executes the procedure as follows:

Opens the procedure file (.p or .r) or procedure library (.pl), if the library is not already open.

Reads the r-code procedure into memory and creates an r-code directory entry for the procedure. OpenEdge first compiles a procedure into r-code, if necessary.

Registers each required r-code segment in the execution environment as follows:

Loads the r-code segment at the head of the segment chain in the execution buffer.

Adds an r-code segment entry to the segment descriptor table that references the segment in the execution buffer.

Inserts a segment descriptor reference in the r-code directory entry for the procedure.

If all the required r-code segments do not fit in the execution buffer, OpenEdge attempts to free space by swapping r-code segments already in the buffer to the session sort file. If OpenEdge cannot free enough space by swapping segments, it increases the execution buffer ceiling and allocates more space for the execution buffer.

Note: When accessing r-code procedures stored in a standard library, OpenEdge does not swap r-code segments to the session sort file unless you specify the PROLIB Swap (-pls) startup parameter. By default, if OpenEdge needs an r-code segment in a standard library, it reloads the segment into the execution buffer from the library in local memory.
Codepage-converted text segments within standard procedure libraries are swapped in and out of the session sort file, preserving any code page conversions that occurred during the initial load of the text segment.

Once the required r-code segments in the procedure are registered in the execution environment, the interpreter begins executing the r-code procedure at the start of the first main action code segment and accesses the remaining segments directly from local memory as required.

Standard execution environment limits

The number of standard r-code procedures that you can run at one time and the memory used are determined by the following factors:

R-code directory size — The default is 100 entries, the minimum is 5 entries, and the maximum is 500. You can set the initial number of entries using the Directory Size (-D) startup parameter. OpenEdge dynamically increases the directory size up to the maximum, as required. Use the Hardlimit (-hardlimit) startup parameter to force OpenEdge to adhere to the limit specified by the Directory Size (-D) startup parameter.

Execution buffer ceiling — The default is 3096K. You can set the initial ceiling for this buffer up to 65,534K using the Maximum Memory (-mmax) startup parameter. OpenEdge dynamically increases the execution buffer size up to the maximum, as required. Use the Hardlimit (-hardlimit) startup parameter to force OpenEdge to adhere to the limit specified by the Maximum Memory (-mmax) startup parameter.

Available memory — Available memory is a factor only if it is smaller than the execution buffer ceiling or OpenEdge needs to allocate memory beyond that ceiling.

Standard r-code segment management

While OpenEdge loads an r-code file, all of its segments are locked in memory. After all required segments are loaded for the procedure, OpenEdge unlocks all segments except its main action code segments and text segment. These segments stay locked in memory until execution of the r-code file terminates. Internal procedure action code segments stay locked only until they return to the invoking procedure and are relocked each time they execute.

When a standard r-code segment does not fit in the execution buffer, OpenEdge attempts to free space by swapping r-code segments already in the buffer to the session sort file. OpenEdge can swap out any unlocked segments. OpenEdge removes these segments from the tail end of the execution buffer chain, in least recently used (LRU) order.

If OpenEdge cannot free enough memory for a newly loaded segment by swapping out older segments, it dynamically increases the maximum execution buffer size (execution buffer ceiling) and allocates the required memory up to the memory available.

When OpenEdge needs a segment that has been swapped to the sort file, it reloads the segment from the sort file into the execution buffer. However, OpenEdge keeps the reloaded segments in the sort file.